home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20010921-20020314 / 000245_robert@bonomi.invalid_Sat Dec 15 13:21:05 EST 2001.msg < prev    next >
Text File  |  2020-01-01  |  6KB  |  126 lines
  1. Article: 13070 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!panix!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!newsfeed.cwix.com!feed.news.qwest.net!news.uswest.net.POSTED!not-for-mail
  3. Newsgroups: comp.protocols.kermit.misc
  4. References: <9vb3i1$989$1@watsol.cc.columbia.edu>
  5. Sender: robert@bonomi.invalid
  6. From: robert@bonomi.invalid
  7. Originator: robert@bonomi.invalid
  8. Organization: Robert Bonomi Consulting
  9. Subject: Re: C-Kermit 8.0 files/installation?
  10. X-Newsreader: trn 4.0-test69 (20 September 1998)
  11. Originator: bonomi@news2.bonomi.com (Robert Bonomi)
  12. Lines: 106
  13. Message-ID: <N%LS7.255$fb1.172478@news.uswest.net>
  14. Date: Sat, 15 Dec 2001 17:46:21 GMT
  15. NNTP-Posting-Host: 168.103.248.65
  16. X-Trace: news.uswest.net 1008438381 168.103.248.65 (Sat, 15 Dec 2001 11:46:21 CST)
  17. NNTP-Posting-Date: Sat, 15 Dec 2001 11:46:21 CST
  18. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13070
  19.  
  20. [ reply note: I'm not an invalid, but a dot-com ]
  21.  
  22.  
  23. In article <9vb3i1$989$1@watsol.cc.columbia.edu>,
  24. Frank da Cruz <fdc@columbia.edu> wrote:
  25. >
  26. >I'm still in a quandary about how to package C-Kermit 8.0.
  27. >Previously it came with all sorts of .ini, .txt, and other files,
  28. >which few people wanted or knew what to do with.
  29. >
  30. >In C-Kermit 8.0, the initialization file is probably unnecessary
  31. >for most people, and the *.txt files have been converted to HTML
  32. >and put up on the Kermit website.
  33.  
  34. Comment: Documentation in HTML is nice, "pretty", makes it easy to cross-
  35.          reference things.  All good reasons for using it.  
  36.  
  37.      *HOWEVER*, please don't make it the _only_ form that things are 
  38.      available in!  Sometimes a web-browser is *NOT* 'conveniently
  39.      available'.  "Plain text" is *universally* readable with simple
  40.      tools, and can be much faster to use to find specific info. e.g.,
  41.      vi and a '/' search, will have the job done, _before_ a browser
  42.      finishes initializing itself.
  43. >
  44. >Thus, if you download C-Kermit (in some form) from the net, you
  45. >can probably also consult the web pages the same way, rather than
  46. >installing plain-text versions of them on your computer and
  47. >putting them somewhere that nobody can find.
  48.  
  49. As an alternative, consider what Hylafax does -- it provides for customizations
  50. in the Makefile as for where to install the configuration files and secondary
  51. documentation. the makefile target for installing the manpages includes editing
  52. to indicate the _actual_ locations on the installed system.
  53. >
  54. >Furthermore, we want the tarball and zip archives to be as small
  55. >as possible.  If we include all sorts of extra files in them,
  56. >they will take much longer to download (e.g. on 56Kb connections)
  57. >and most people will be annoyed when they find out why.  Separating
  58. >into separate taballs for text files and program files, as we have
  59. >done in the past, is confusing too.
  60.  
  61. This is indicative of a 'documentation failure', not a flaw in the approach.
  62. And much easier to remedy.  Appropriate language in the release announcement
  63. and the  'download' web-page -- e.g. "downloading the Supplement is _not_
  64. necessary for a working Kermit installation"
  65.  
  66. >I'm beginning to convince myself that there is no reason why the
  67. >Unix C-Kermit 8.0 tarball should include anything but the source
  68. >code, the license, the manual page, and a brief read-me. 
  69.  
  70. There are a few other 'necessaries', too.  see below.
  71.  
  72. >                                                          All the
  73. >other stuff is just confusing -- people tend to think they NEED to
  74. >install those files or else C-Kermit won't work, which isn't true;
  75. >the executable does its job just fine without any external files
  76. >at all, and now that its default settings (e.g. file-transfer
  77. >performance tuning, 8-bit-cleanliness, etc) are in tune with
  78. >modern times, there is little need for anything but the binary
  79. >itself, except when users want to do their own customizations.
  80. >
  81. >Thus the Unix "make install" target can be radically simplified,
  82. >as can the construction of install packages like RPMs.
  83.  
  84. Absolutely.  at most it should have a 'hook' to an _external_ "make install"
  85. for the  Supplement
  86. >
  87. >Meanwhile, people who are not on the network and who order
  88. >C-Kermit on CDROM or tape or whatever will get everything, so
  89. >no worries.
  90. >
  91. >Opinions?
  92.  
  93. Suggest, despite your prior 'confusion' experience, multiple tarballs.
  94.  
  95.     The first one ("core distribution"):
  96.      README
  97.      INSTALL
  98.      license
  99.      source-code
  100.      manpage
  101.          changes  (aka "whats new")  [ by version, *cumulative*, not just 
  102.             'new with this version')
  103.          known bugs/problems this version (a la the BWR files)
  104.  
  105.    Then, there's going to be a bunch of documentation, etc. that is *not*
  106.      'platform-specific', and not essential to proper program operation.
  107.      put that in a second tarball (the "supplement").
  108.    
  109.    Lastly, there are things that _are_ platform-specific, e.g. MVS and 7171
  110.      front-end mapping issues,  VAX-isms, etc.  Make a tarball _per_
  111.      _platform_ of this stuff.  (the 'platform-specific' "Appendix")
  112.  
  113.    A "binary" distribution could then consist of:
  114.      README
  115.      INSTALL (for binaries)
  116.      License
  117.      executable(s) and req'd support files (if any)
  118.      manpage
  119.      changes
  120.      known bugs
  121.      the O/S-specific "Appendix" (as a "tarball in a tarball" -- the 
  122.         "installer" routine needs to know *only* how to unpack the tarball,
  123.         and _invoke_ the 'make install' (or equivalent) contained therein.)
  124.  
  125.  
  126.